… visuals

Set modules.contentControls.chrome: 'none' so the demo shows the
intended SD-3159 use case: built-in SDT chrome off, host owns the
visuals. Smart-field pills and clause cards are now host-painted under
.superdoc-cc-chrome-none (scoped so they sit above the painter's reset),
and the painter-label CSS is dropped since no label element is emitted.
The contextual field chip is unchanged and still anchors via getRect,
which keeps working because wrappers and data-sdt-* datasets are kept.

…rder

Cover the :hover ::before/::after suppression selectors and add an
order assertion: the chrome-none block must be declared after the
lock-hover ::before rule. Those hover selectors are equal specificity
to the rules they override, so source order is what makes them win;
the assertion guards against a future reorder silently re-leaking
hover chrome under contentControlsChrome=none.

Close review-feedback coverage gaps for modules.contentControls.chrome:
- SuperDoc.test.js: assert SuperDoc.vue forwards
  modules.contentControls.chrome into the PresentationEditor layout
  options (and stays undefined when unset). This is the public consumer
  path; DomPainter unit tests exercised the option but not the wiring.
- consumer-typecheck: pin that modules.contentControls.chrome: 'none'
  compiles for a consumer across the tsconfig matrix.
- table tests: assert chrome: 'none' suppresses the label but keeps the
  wrapper for a table-level SDT and a nested-table SDT in a cell; the
  threading through fragment/row/cell had no coverage.
- virtualization.test.ts: restore the page-0 eviction assertion that the
  PR had dropped, so the remount test again proves eviction happened
  first (verified it still passes).
- styles.ts: scope the chrome-opt-out comment to structured-content
  labels; documentSection chrome is intentionally preserved.

contentControls has a single real runtime option: SuperDoc.vue reads
modules.contentControls.chrome and forwards nothing else. The
& Record<string, unknown> intersection (mirrored from sibling module
configs that genuinely forward extra keys) gave no typo safety for the
new public option, and made the consumer fixture pin a pass-through
contract that does not exist. Drop the index signature and the fixture's
forwardedFlag so an unknown contentControls key is now a compile error.

The header claimed every modules.X shape is intentionally open. That is
now false: configs that forward runtime extras stay open, but
contentControls (one real option, no forwarding) is intentionally exact.
Reword so the file documents both policies. Comment-only.